HaCKeRz Kr0nlcKLeZ 1

home *** CD-ROM | disk | FTP | other *** search

/ HaCKeRz Kr0nlcKLeZ 1 / HaCKeRz Kr0nlcKLeZ.iso / chibacity / normanav.exe / README.NOW < prev next >

Wrap

Text File | 1995-06-19 | 58.7 KB | 1,299 lines

Norman Virus Control for Workstations "Armour" version 3.47 Copyright (c) 1993 - 95 Norman Data Defense Systems RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and/or FAR 52.227-19. Norman Data Defense Systems, Inc. 3028 Javier Road, Suite 201 Fairfax, VA 22031 USA This text file contains recent information that has not yet been added to the manual. Please read this first and make notes in your manual before installing. ************************************************************************** NOTE: There have been significant changes in the installation procedure since the manual was printed. Please refer to the Section 3.0 below called "Understanding the Installation Process" for an update. ************************************************************************** Corrections to Section 1.5.1.1 "NVC.SYS" The "installation" paragraph should read: "By default, NVC.SYS is copied to the C:\NORMAN directory. NVC.SYS is loaded as high up in CONFIG.SYS as possible. If you are using configuration blocks in CONFIG.SYS (a feature of MS-DOS 6.00+), then NVC.SYS is loaded in the [common] block. If QEMM is being used with the /ST parameter, then NVC.SYS is loaded with the /A parameter. See section 5.1.4.1.4 for more details on /A. If 386Max is being used, then NVC.SYS is loaded with the /T parameter. See section 5.1.4.1.3 for more details on /T. Note: if you are manually loading NVC.SYS into CONFIG.SYS, then NVC.SYS must be loaded after HIMEM only if DOS is being loaded high. In addition, if CONFIG.SYS contains a line with the device driver IFSHLP.SYS, NVC.SYS must be loaded after this line. NOTE: To avoid potential conflicts, 32 bit disk and file access should be turned off when using NVC.SYS. If you need to have 32 bit access turned on, consider using CANARY.* instead of NVC.SYS. ** Please apply all these changes to section 3.1.1. See below for more corrections to section 3.1.1. ** Correction: Section 1.5.1.11 "NOSTELTH" and Section 5.8 "NOSTELTH" NOSTELTH.COM is no longer being shipped on the Armour DOS and Windows diskette. Instead, you may find it on the Armour Power Tools diskette. Correction: Section 1.5.1.12 "WININST" WININST is no longer being shipped on the Armour diskettes. Correction: Section 1.5.1.13 "ISWIN" ISWIN is no longer being shipped on the Armour diskettes. Correction: Section 1.5.2.1 "NVC for Windows" CPBITMAP.DLL is no longer being shipped on the Armour diskettes. NORMAN.GRP will be installed to the C:\NORMAN directory, not to the C:\WINDOWS directory. NVCW.ICO is no longer being shipped on the Armour diskettes. Correction: Section 1.5.2.4 "WINTEST" WINTEST is no longer being shipped on the Armour diskettes. Addition: Section 1.5.5 "TCP/IP Extension Modules" Through version 3.42 of Armour, our messaging features were handled through IPX communications. In Armour v3.46, however, you have the option of receiving Armour components which can generate SNMP traps for use in messaging throughout PC-NFS and Lan Workplace environments. SNMP is a protocol which controls and monitors TCP/IP-based networks. An SNMP management station may poll an SNMP agent to obtain information about the agent system. The management station uses UDP (User Datagram Protocol) on port 161 to send a PDU (Protocol Data Unit) containing such a request. A system does not have to be polled to transmit information to the management station. Another SNMP mechanism is called "traps". An SNMP agent may sent a trap message to the management- station without being polled. This is typically done when something extraordinary has occurred. In this case, a trap message is sent when a virus is detected. UDP port 162 is used for SNMP traps. Contents of the installation disk: The Armour installation disks for PC-NFS and Lan Workplace environments contain the same filenames. However, the programs are unique for each TCP/IP environment. Following is a list of files included on each disk: readme.txt: This file contains any last-minute changes to the user manual. install.bat: A simple installation routine which copies the files from the disk to a target directory. systems.txt: An ASCII configuration file which contains a user-defined message (to be displayed when a virus is detected) and the names of the servers that are to be notified by the agent. This file is an example only. Users must modify this file according to their own needs. setup.exe: A configuration program that compiles the file "systems.txt" into "tcp_ip.cfg", which is the configuration file used by the agents. nvc.exe: A replacement for the DOS command-line virus scanner. nvcw.exe: A replacement for the Windows virus scanner. nvs.exe: A replacement for the Windows scanner scheduler. nvcsys.exe: A replacement for the Windows agent that communicates with NVC.SYS. ip_test.exe: This program sends a dummy trap to the list of management stations specified in the configuration file "tcp_ip.cfg". It may be helpful when troubleshooting an installation. System Requirements: The only requirement to make the Armour TCP/IP extension work on a system is that a matching TCP/IP protocol stack and environment is installed on the system. Before installing the extension, make sure that TCP/IP is up and running by issuing a "ping" command or something similar. Installation: IMPORTANT: you must first install the original (non-TCP/IP) Armour components and then install the TCP/IP extension. The TCP/IP installation disk contains replacement modules for the original Armour programs. Therefore, it is very important that the TCP/IP extension disk you are using has the same version number as the Armour programs that are already installed. For example: If you have Armour v3.46 installed on your system, and you wish to install the TCP/IP extension for Lan Workplace, then you need to install version 3.46 of the TCP/IP extension. In the future, ensure that you receive both the original Armour components and the TCP/IP extensions as upgrades. When using NVC.SYS with the TCP/IP extension for PC-NFS, it is important that you use the /T parameter on NVC.SYS. NVC.SYS will not co-exist with PC-NFS without this parameter. Failure to include the /T parameter may cause the PC to hang. Inclusion of the /T parameter will not impair the ability of NVC.SYS to detect unknown viruses. The difference lies in when the virus is detected. When the /T parameter is used, the virus will be detected as it tries to infect, and not when it goes resident in memory. Copy all the files from the disk into the directory where your Armour programs reside. You may also use INSTALL.BAT by typing install c:\norman where "c:\norman" is the directory where Armour resides. Configuring the installation: After copying the files from the TCP/IP extension disk into the Armour directory, you are ready to configure the system. This is done by editing the file "systems.txt". Use DOS EDIT, Windows Notepad, or any other ASCII editor for this task. "systems.txt" contains a list of the machines in the network where SNMP traps are to be sent. You may also enter a text string that will be included with the trap. An example of "systems.txt" is shown below: ; Norman Data Defense Systems TCP/IP server name file ; ; This file lists the names of the servers that are to ; be notified in case of a virus incident. Lines starting ; with ';' are ignored and can be used for comments. Up ; to 150 server names may be given in this file. ; A system name cannot exceed 8 characters in length. ; A system may only occur once in the file. ; A custom-designed message of 70 characters (max.) may be ; included on any separate line, starting with the character '@'. ; This brief message may be used to identify the sending system ; and its location, etc. ; norman einstein ; @This is a custom message line. ; As you can see in the example, comments may be included on any line by starting the line with a semi-colon. You can include a custom message by starting a line with the character "@". In this example, SNMP traps will be sent to the machines "norman" and "einstein". It is necessary that these machines are available in the "hosts" table on the workstation or its name server, so that valid IP-addresses can be resolved from the names. After you have edited the "systems.txt" file, you must compiled it and create the file "tcp_ip.cfg". "tcp_ip.cfg" is created by running "setup.exe". Testing: A test program called "ip_test.exe" is included on the TCP/IP extension disk. This program will send a test-trap to the systems specified in "tcp_ip.cfg". "ip_test" will return a variety of messages, depending on whether or not the operation ended successfully. The MIB id for the test-trap is "Internet.1007.1.7". There are 3 command-line parameters for ip_test.exe: Parameter Meaning /F<text> Send alternate file location string /T<number> Send alternate enterprise trap number /V<text> Send alternate virus name string Using these parameters, it is possible to send any file location string, enterprise trap number and virus name string to the systems. Using this feature makes it easy to customize the service routines at the receiving end. Remember that the specific trap number indicates wether a virus is normal (1) or dangerous (2). Troubleshooting: The following are explanations of some of the error messages that may be displayed by the configuration program (setup.exe) and the test program (ip_test.exe). Configuration program error messages: The configuration program (setup.exe) uses the data contained in the file "systems.txt" in order to generate a configuration file. This is a short overview of some of the error messages that may be encountered when running "setup.exe": Error in line x: Server name is too long: <name>. Error in line x: Illegal character in position y of name: <name>. Error in line x: Duplicate name: <name>. Error in line x: Customized message is too long. Line ignored. The messages above all refer to errors with the system names and custom message in "systems.txt". To correct an error, edit the file again. The error messages should tell you on which line the error is located. Error: Cannot find systems name file. Error: Cannot open systems name file. These two messages appear if there is a problem with the file "systems.txt". Make sure that this file exists in the directory from which you ran "setup.exe". Error: Cannot open configuration file. Error: Could not write to configuration file! These two messages appear when, for some reason, the setup program is unable to create the file "tcp_ip.cfg". Make sure that there are enough file handles available and that there is room enough on your disk. Warning: No system names given! This message appears if there are no system names in "systems.txt". "setup.exe" will still generate a configuration file, but no traps will be generated by the applications. Test program error messages: The test program, "ip_test.exe", will normally terminate with the following message: Trap PDU sent, Result OK! This means that a trap was successfully generated and sent to the systems specified in "systems.txt". The program will list the systems to which it is sending traps. If the list does not match the systems that you specified in "systems.txt", you will have to run "setup.exe" again in order to generate a new configuration file. If you enter an illegal command-line parameter for "ip_test.exe", the following will appear: Illegal option: <option> The following are brief descriptions of other error messages that may be produced by "ip_test.exe": Cannot open configuration file. The configuration file "tcp_ip.cfg" is not available in the Armour directory. The client is not installed. The local TCP/IP environment is not installed and/or is not running. Configuration file checksum error! The configuration file "tcp_ip.cfg" is defective. Generate a new one using "setup.exe". Unable to generate PDU! Could not allocate buffer! Out of memory error, xxx. All three of these messages are a result of a lack of free memory on the local system. Could not read configuration file. There is a problem reading "tcp_ip.cfg". This is most likely because of a problem in the DOS environment. Could not open endpoint! There are problems with the port at the receiving end of the connection. Version verification failure! This error occurs if your configuration file (tcp_ip.cfg) was generated in a format not compatible with the current version of the TCP/IP agent. Run "setup.exe" from you latest version of the TCP/IP extension package. Configuration file is empty! This message means that your configuration file does not contain any systems to send traps to. Edit "systems.txt". Could not send to system name no.x! This means that the program was unable to establish a connection with the specified system. Usually this is because the receiving system is down. If many systems are not responding, only the last one will show in the error message. System name no.x is not valid! This means that the specified system does not resolve to a valid IP-address. Check that the system appears in your hosts-file or at your name server. Technical issues: Detailed description of Norman SNMP traps: Products from Norman Data Defense Systems have their own place in the SNMP MIB tree. The following illustration (Figure 1) shows the structure of this tree. When a trap is sent from any of the anti-virus applications, the trap number is 6, which means that the enterprise-specific trap number is set. The enterprise-specific trap from Norman anti-virus programs indicates whether the virus that has been discovered is dangerous or not. Specific trap number 1 indicates regular viruses, while number 2 indicates dangerous viruses. Figure 1: Norman in the MIB tree . . ┌─────────────────┐ │ Internet │ │ 1 │ └─────────────────┘ . . ┌─────────────────┐ │ Private │ │ 4 │ └─────────────────┘ . . ┌─────────────────┐ │ Enterprises │ │ 1 │ └─────────────────┘ . . ┌─────────────────┐ │ Norman │ │ 1007 │ └─────────────────┘ . . ┌─────────────────┐ │ Anti-Virus │ │ 1 │ └─────────────────┘ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ NVC.SYS│ │NVC.EXE │ │NVCW.EXE│ │ TEST │ │ 1 │ │ 2 │ │ 3 │ │ 7 │ more to be added └────────┘ └────────┘ └────────┘ └────────┘ in the future Therefore, traps that are sent from Norman applications have the following ID's: nvc.sys .1.3.6.1.4.1.1007.1.1 nvc.exe .1.3.6.1.4.1.1007.1.2 nvcw.exe .1.3.6.1.4.1.1007.1.3 ip_test.exe .1.3.6.1.4.1.1007.1.7 There is a variable bindings list included in Norman virus-traps. It consists of four octet strings containing information about the virus attack. Octet-string no.1: This string contains the origin of the message (user login and machine name). Octet-string no.2: If possible, this string indicates the name of the virus that has been detected. Octet-string no.3: This string indicates the location (filename) of the virus. Octet-string no.4: Contains the user-defined message included in the local "tcp_ip.cfg" configuration file. Correction to Section 3.0: "Understanding the Installation Process" Our installer, NVCINST.EXE, has undergone major revisions since the manual for Norman Virus Control for Workstations ("Armour") has gone to press. This section describes the updated functions. Summary of the disks you can get with Armour: Armour's DOS and Windows components are shipped on one diskette. This, along with the Armour Power Tools, and Norman V-Base, is the standard shipment. At no extra cost, you can request Armour's OS/2 components (command- line scanner, PM scanner and PM scheduler). Again, at no extra cost, you can also request Armour's SNMP extensions for Lan Workplace for DOS and/or PC-NFS. Corrections to Section 3.1 and Section 3.1.1 "Installing from the Distribution Diskettes" To install from the Armour for DOS and Windows diskette, simply place the diskette in drive A: (or B:), change to that drive, and type "INSTALL". All your local drives will be scanned first. If no viruses are found, then installation proceeds normally. If a virus is found, we will attempt to remove it. All results will be logged to the file C:\NVC.RPT. Unlike previous versions, installation consists of copying both the DOS and Windows files over to the C:\NORMAN directory and placing several lines in AUTOEXEC.BAT and CONFIG.SYS. No separate install is necessary for the Windows modules. The Windows modules will be installed in the fashion described in Section 3.1.2 in the manual with these exceptions: * the installation directory will be C:\NORMAN * the NORMAN.GRP will be called from C:\NORMAN * no icon for V-Base will be made * all references to the file VBASE.PIF should be ignored. * all references to NVCW.ICO should be ignored. Our device driver, NVC.SYS will be called from CONFIG.SYS, along with TBDRIVER.EXE. In AUTOEXEC.BAT, we call TBSCANX (a resident scanner), BG.EXE (BootGuard, our boot area protection), and CANARY (an alternative to checking for resident viruses). If you are low on memory, we suggest that you not run TBSCANX but continue to use BG.EXE. In the Windows directory, we modify PROGMAN.INI to add the NORMAN group file which is called from the C:\NORMAN directory. In addition, we modify WIN.INI to add "c:\norman\nvcsys.exe" to the end of any existing "load=" line. A log of the installation process will be kept in C:\NORMAN\INSTALL.LOG. Corrections to Section 3.1.3 "What happens during installation from Disk 3" There is no longer a Disk 3. The modules listed in this section are Armour's OS/2 modules, and they are contained on the optional, free (upon request) diskette labeled: "Armour for OS/2 v2.1+" There is not an INSTALL.BAT but rather an INSTALL.EXE. There is now an OS/2 version of the program NVCEXCL.EXE. Please see section 5.6 for a discussion of NVCEXCL.EXE. There are two help files for OS/2: EHBOK.INF (The Norman Book on Viruses) and NVCHLPE.INF (the manual in help format). Corrections to Section 3.2 "Customizing NVCINST" Replace this entire section in the manual with the following: Instead of specifying command line parameters for NVCINST, you can control your installation of Norman Armour by editing the file NVCINST.INI. NVCINST.INI is shipped on the Armour diskette, but if your copy is corrupted, or if you wish to see the defaults, simply rename NVCINST.INI to another filename and then type "NVCINST". A new copy of NVCINST.INI will be created for you. You may edit NVCINST.INI as you wish. The default contents are as follows: ; This file is NVCINST.INI ; It controls the installation process for Norman Armour. ; You may edit it as you see fit to control how an installation will occur. ; Comments begin with a semi-colon. Sections are shown in [square brackets], ; and are provided only to improve readability. Sections may be listed in ; any order. Text may be entered in UPPER CASE, lower case, or Mixed Case ; as you wish. You may use spaces around the `=' in the parameters using ; this syntax. ; To see the original (default) file, simply rename this to another name and ; run NVCINST again. NVCINST will generate a new copy of this file. ; It is recommended that NVCINST be run from a batch file, and that earlier ; in the batch file you include these lines (without the `;'): ;nvc /ald /y /cl ; (add error level traps here if desired) RESTRICTED RIGHTS: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and/or FAR 52.227-19. Norman Data Defense Systems, Inc., 3028 Javier Road, Suite 201 Fairfax, VA 22031 USA. [InstallIf] ; This section controls when an install will occur. ; You can choose to install if NVC.SYS is not running with this line: Installif=NvcSysNotRunning ; You can choose to install if any of the files you wish to install is newer ; than any existing copy of the file in the destination directory with ; this line: Installif=Newer ; By using both switches, you will install if either condition is met. [CopyWhatToWhere] ; This instruction is ideal for installs from the server, where free space ; is not a problem. For installs from floppy, you may either use the COPY ; instruction, or use the EXTRACT instruction (see below). ; Syntax is COPY [FILENAME] to [DESTINATION] ; Files not listed will not be copied. ; If the destination directory does not exist, it will be created. ; If a source directory is not specified, the current directory is assumed. ; You may add as many source files here as you wish. The following files will normally not be compressed on the source, so that the scanner and cleaner can be called by your install.bat. COPY NVC.* to C:\NORMAN COPY NVCLEAN.EXE to C:\NORMAN COPY TBAV.KEY to C:\NORMAN COPY README.NOW to C:\NORMAN ; => To use the COPY instructions below, remove the semi-colons. ;COPY BD.EXE to C:\NORMAN ;COPY BG.EXE to C:\NORMAN ;COPY CANARY.* to C:\NORMAN ;COPY CPALETTE.DLL to C:\NORMAN ;COPY DOSTEST.* to C:\NORMAN ;COPY EHBOK.HLP to C:\NORMAN ;COPY MANUAL.XDB to C:\NORMAN ;COPY NARCH.PIF to C:\NORMAN ;COPY NORMAN.GRP to C:\NORMAN ;COPY NPR.EXE to C:\NORMAN ;COPY NVC.INI to C:\WINDOWS ;COPY NVCEXCL.EXE to C:\NORMAN ;COPY NVCHLPE.HLP to C:\NORMAN ;COPY NVCSYS.EXE to C:\NORMAN ;COPY NVCW.EXE to C:\NORMAN ;COPY NVS.* to C:\NORMAN ;COPY RC.* to C:\NORMAN ;COPY S-CAN*.* to C:\NORMAN ;COPY SCANMENU.* to C:\NORMAN ;COPY SCINST.* to C:\NORMAN ;COPY TB*.* to C:\NORMAN ;COPY VIEW.EXE to C:\NORMAN [Extract] ; Extract permits installation from a self-extracting ZIP file. ; This instruction is ideal for installs from floppy disk, where space ; is a premium. ; Syntax: ; ExtractFrom=[drive:\path\source file] ; ExtractTo=[destination drive:\directory] ; ExtractWhat=[file name to extract] ; Examples: ExtractFrom=armour.exe ExtractTo=c:\norman ExtractWhat=*.* [Config.Sys] ; To call NVC.SYS (Norman's powerful virus behavior blocker) ; simply set nvcsys=yes NvcSys=yes ; Provide the command line you want for NVC.SYS ; For maximum compatibility with your software, set NvcSysSwitches=/T /F ; For compatibility with access control software, set NvcSysSwitches=/A ; For compatibility with a SCSI controller, set NvcSysSwitches=/A ; For standard, strong protection, set NvcSysSwitches=none ; For the strongest protection possible, set NvcSysSwitches=/E ; See the manual for your custom settings. NvcSysSwitches=none ; To load NVC.SYS high, use NvcSysHigh=yes NvcSysHigh=yes ; To run TBSCANX (Norman's resident virus scanner) you should load ; TBDRIVER in CONFIG.SYS. tbdriver=yes ; You can provide TBDRIVER with any switches you wish (see manual.) ; Default is none tbdriverswitches=none ; if you want to backup CONFIG.SYS to a specific filename, ; simply specify the name of the backup file here like this: ;backupConfigTo=c:\config.bak [Autoexec.Bat] ; if you want to add BootGuard to Autoexec.bat, use this parameter: bootguard=yes ; TBSCANX (Norman's resident virus scanner) can be loaded from AUTOEXEC.BAT. tbscanx=yes ; You may specify any switches you wish for TBSCANX (see manual.) ; none means that no switches are desired. Useful switches include: ; allexec (scan files on all drives prior to execution, not just floppies) ; ems (use expanded memory if available, saving on conv. memory use.) ; xms (use extended memory - slower than ems, but uses less conv. ; memory than if you use neither ems nor xms switches.) ; compat (increase compatibility with some TSR that loads after it.) ; lock (lock the PC when a virus is detected) ; secure (deny user access to infected file, without asking them for best ; course of action.) ; none (no switches for tbscanx) ; Such options may be combined as in our default setting: tbscanxswitches=allexec ems compat ; if you want to add Canary to Autoexec.bat, add a line like this canary=yes ; Canary can be installed with any of several switches - see manual. ; We recommend switch 1 as shown below: canaryswitch=1 ; if you want to backup AUTOEXEC.BAT to a specific filename, ; simply specify the name of the backup file here like this: ;backupAutoexecTo=c:\autoexec.bak [NoiseLevel] ; You can choose how much information is displayed on the screen during a ; normal install. ; For completely ■silent■ operation - no screen output - choose Noise=silent ; For operation which displays only errors when found, choose Noise=errorsonly ; For operation which displays what is happening, choose Noise=loud Noise=loud [ErrorLog] ; You can record what has happened during the installation in a log file if ; you specify a log file. ; You might say Log=c:\norman\install.log to create a local log. ; To record the log on the server, in a directory where all users have write ; permission, first give all users write permission in some directory, then ; specify it with this parameter. log=c:\norman\install.log ; You should specify whether the log should be overwritten or appended to. ; For a log of all installs, choose Append. To create a new log, enter ; action=overwrite action=overwrite [ReadMe] ; You may specify a file to be displayed prior to installation ; and after installation with these settings: preReadme=readme.1 postReadme=readme.2 If you wish users to see the error log at the end of the install, simply specify its fully qualified name (as specified in log= above) in the postReadme= line above. Corrections to Section 3.3 "Installing from the Network" You may still use NVCINST to install the DOS and Windows portions of Armour over the network. Simply use NVCINST and NVCINST.INI in the same fashion as you would during a manual install to a workstation. * In the manual, ignore the paragraphs that are preceded by "Method 1" and "Method 2". * In the manual, ignore the paragraph that pertains to installing the OS/2 components over the network. In the subsections 3.3.1 and 3.3.2, ignore any statements about using parameters for NVCINST. NVCINST's functions are now all directed by the contents of NVCINST.INI. Note on Section 5.1.6 "Help Menu" You may access our context-sensitive help from any of the Windows scanner's dialog boxes. The Windows help file that accompanies this version of Armour, however, is currently being revised, so you will experience some disparity in the text. We apologize in advance for the inconvenience. Correction to Section 4.0 "Removing Viruses" Where NOSTELTH is referenced, please look to the Armour Power Tools diskette to locate the NOSTELTH program. Addition: Section 5.1.4.1.9 "NVC.SYS and 32 bit access" The current version of NVC.SYS was not written to be completely compatible with 32 bit access. If you have a choice, please turn 32 bit access off. Addition: Section 5.1.4.1.10 "NVC.SYS and Additional BIOS" If NVC.SYS is giving you a warning, and you think it is a false alarm, it might be due to having an additional BIOS on an additional board (these are common in Pentium machines). If this is the case, use NVC.SYS with the /A parameter. Warning: when /A is used, NVC.SYS will not detect boot viruses going into memory. To find out if the NVC.SYS warning is a false alarm, either: 1) press "C" when you are warned, put a write-enabled floppy in Drive A:, and then access A: with a command such as "DIR A:". If NVC.SYS does not warn again, then the original warning from NVC.SYS is a false alarm. If NVC.SYS does warn, then you have a boot virus. Press "B" to disable the virus in memory, boot from an uninfected bootable diskette, and run NVCLEAN against your hard drive. or 2) boot from an uninfected bootable diskette and scan your hard drive using NVC.EXE. If a virus is found, then use NVCLEAN to remove it. Addition to the Armour package: Automatic Scanning and Virus Protection with TBScanX and TBDriver 1.0 Introduction and Overview Norman is now shipping two memory resident components that help watch over your computer, protecting it from viruses: TbDriver and TbScanX. The technology for these components was developed by Thunderbyte, one of Norman's partners. (Hence the "Tb" in the names of these modules.) The modules described here have been carefully tested for compatibility with Norman's other anti-virus modules, and are now being integrated with Norman Armour. This supplement to the Armour manual will be superseded in the next few months by a single manual integrating all of our modules. This manual describes two modules which work together, from memory, to prevent the introduction of a virus to your computer and which provide instant identification of any virus that comes along. This approach complements Norman Armour's NVC.SYS, which provides smart behavior blocking. NVC.SYS stops both new viruses that have been recently written and older viruses. The modules described here specialize in the existing viruses for which names are known. By using the two modules described in this document, you will instantly get a name for any virus for which we know the name, and always get a warning. But the modules in this manual don't merely name the viruses that are coming into your computer. Norman's NVC.SYS can only stop a file virus when it is "behaving" - trying to go into memory, for instance, or trying to infect a file. The modules described here don't merely scan when you execute a file, stopping infected, but they also scan on file copy, create, download, modify, or unarchive. Thus your virus stopping power will be 100% when using the double layer of protection afforded by NVC.SYS and the modules described in this manual. That double layer of protection is important, for an increasing number of viruses are being written to get past a given TSR. Virus authors all seem to know the simple code needed to remove Central Point's TSRs from memory. But your chance of finding a virus in the future that can get past both NVC.SYS and TBScanX is essentially 0. The double layer of protection comes at little expense to your daily operation. After loading both modules, conventional memory may be reduce by only 1K. Actual machine operation will not detectably slow, as it does with many other TSRs. In fact, you will be hard pressed to devise a benchmark that shows any slowdown at all. TbDriver provides basic protection against ANSI bombs and stealth viruses. It also serves as a support module for TbScanX, our automatic, resident scanner. TbScanX is a signature scanner which remains resident in memory and automatically scans those files which are being executed, copied, de-archived, downloaded, etc. TbScanX does not require much memory. It can swap itself into expanded, XMS, or high memory, using only 1Kb of conventional memory. (Armour's NVC.SYS can be loaded high, using no conventional memory.) We will begin by describing TbDriver. 2.0 TbDriver 2.1 Purpose of TbDriver TbDriver must be loaded in advance to enable the memory resident TbScanX to perform properly. It is the source for some of routines, including support to generate the pop-up window routines, driving the translation unit which enables the possibility of displaying messages in your native language, and support for networks. In addition, TbDriver also contains basic protection against Stealth viruses and against ANSI bombs. How to use TbDriver TbDriver must be loaded before TBScanX. For loading instructions, please consult the following pages. If you want protection against ANSI-bombs, you should load TbDriver after the ANSI driver. In normal situations it is not necessary to use the 'net' option of TbDriver. If you install TbDriver on a machine that is booted from a boot ROM, specify the message file with the drive and path where it can be found AFTER the machine has booted. The default message file will not be accessible anymore after the machine has booted. 2.2. Command line options TbDriver allows loading options to be specified on the command line. A filename specification will be treated as a language file specification. The upper three options are always available, the other options are only available if TbDriver is not already memory resident. option switch explanation help ? display a help screen. If you specify this option TbDriver will show you the valid command line options as listed below. net n force LAN support remove. TbDriver cooperates well with most networks, so in normal situations option 'net' will not be needed at all. It should be used only if all of the following conditions are true: A connection to a Novell network is made, and TbDriver.Exe is started before the logon command was used, and there is no valid Anti-Vir.Dat record in the directory where the NET?.COM program resides, or after the NET?.COM file has been renamed. mode =<m|c> m override video mode. On dual video systems TbDriver will use the currently active screen. It may be forced to use the alternate screen with option 'mode=m' for monochrome, or 'mode=c' for color systems. noavok=<drives> o assume permission when AV record is missing. quiet q do not display activity. TbScanX displays a rectangle with "*Scanning*" in the upper left corner of your screen while scanning a file. You can disable this with the 'quiet' option when TbDriver is loaded. secure s do not allow permission updates. notunnel t do not detect tunneling. TbDriver normally detects tunneling attempts on the part of viruses. 'Tunneling' is a technique viruses apply to determine the location of the DOS system code in memory, and to use that address to communicate with DOS directly. This will inactivate all TSR programs, including resident anti-virus software. TbDriver is able to detect 'tunneling' attempts, and informs you about this. Some other anti-virus products also rely on tunneling techniques to bypass resident viruses, causing false alarms. If you are currently executing other anti-viral products, option 'notunnel' will disable tunneling detection. nofilter f do not filter dangerous ANSI codes. The original ANSI driver has a feature to assign text strings to keys. Years ago, people used this feature to assign - for instance - the F10 key to the text 'DIR /W'. This reprogramming can simply be done with embedded ANSI codes in text files. Typing such a file with the DOS 'type' command is enough to reprogram the keys. Today, almost nobody uses this feature anymore, but it is still there. Some ill-minded people however use this feature to make a text file which reprograms - for instance - the Enter key to execute the text 'Del *.*', or worse... Such a text file is called an ANSI-bomb. TbDriver protects you against ANSI-bombs by filtering out the keyboard reprogramming codes. All other ANSI codes will pass without interference. If you don't want this protection, or if you want to use this obsolete ANSI feature you can specify option 'nofilter'. nostack ns do not install a stack. By default, TbDriver maintains a stack for TBScanX. For most systems however this isn't necessary. If you specify option 'nostack' TbDriver will use the application stack, saving a few hundred bytes of memory. However, if the system hangs or becomes unstable, you should discontinue use of this option. remove r This option disables TbDriver and will try to remove the resident part of its code from memory in an attempt to restore this memory space back to the system. Unfortunately, this can work only if TbDriver was loaded last. An attempt to remove a TSR after another TSR has been started will simply leave a useless gap in memory and could disrupt the interrupt chain. TbDriver checks whether it is safe to remove its resident code; if not, it will simply disable itself. 2.3. Language support The optional filename specification is used to determine where the language file can be found. TbDriver retrieves pop-up window messages from a TBDRIVER.LNG file, which it expects to find in its own home directory. The default English language file is TBDRIVER.LNG 3.0. TbScanX 3.1. The Purpose of TbScanX TbScanX is the resident version of the TbScan program, checking files on the basis of a virus signature list. Suppose you have a virus scanner automatically executed from your autoexec.bat file. If no viruses are found, your system is supposed to be uninfected. But, to be sure that no virus will infect your system, you have to execute the scanner every time after copying a file to your hard disk, after downloading a file from a bulletin board system, or after unarchiving an archive such as a ZIP file. Once loaded, TbScanX will remain resident in memory, and will automatically scan all files you execute and all executable files you copy, create, download, modify, or unarchive. The same approach is used to protect against boot sector viruses: every time you put a diskette into a drive the boot sector will be scanned. If the disk is contaminated with a boot sector virus TbScanX will warn you in time! TbScanX is fully network compatible. You need not re-load it after logging on to the network. 3.2. How to use TbScanX Since TbScanX is memory resident, the program can be executed and configured from the command line or from within a batch file. It is important to load TbScanX as early as possible after the machine has booted. Therefore it is recommended to execute TbScanX from within the config.sys file. * Note that TbScanX requires TbDriver to be loaded first! Loading TBScanX There are three possible ways to load TbScanX: 1. From the DOS prompt or within the Autoexec.Bat file: <PATH>TBSCANX 2. From the Config.Sys as a TSR (Dos 4+): INSTALL=<PATH>TBSCANX.EXE The "Install=" Config.Sys command is NOT available in DOS 3.xx. 3. From the Config.Sys as a device driver: DEVICE=<PATH>TBSCANX.EXE Note that executing TbScanX as a device driver does not work in all OEM versions of DOS. If it does not work, use the "Install=" command or load TbScanX from within the Autoexec.Bat. TbScanX should always work correctly after being started from within the Autoexec.Bat. Unlike other anti-virus products, the Norman anti-virus utlities can be loaded before the network is started without losing the protection afterwards. Loading TBScanX High In addition to the three invocation possibilities, users of DOS 5 and higher versions can load TbScanX high in UMB (upper memory block) if it is available: LOADHIGH <PATH>TBSCANX.EXE Within the Config.Sys file TbScanX can also be loaded high: DEVICEHIGH=<PATH>TBSCANX.EXE TbScanX and MS Windows Windows users should load TbScanX before starting MS Windows. If you do, there will be only one copy of TbScanX in memory, but every DOS window will nevertheless have a fully functional TbScanX in it. TbScanX detects if Windows is starting up, and will switch itself in multi-tasking mode if necessary. You can even disable TbScanX in one window without affecting the functionality in another window. 3.3. Command line options TbScanX can be configured from the command line. The upper four options are always available, the other options are only available if TbScanX is not already resident in memory. option switch Explanation help ? display a helpscreen. If you specify this option, TbScanX will show you the various command line options shown below. Once TbScanX has been loaded, the help option will not show all options anymore. off d disable scanning. If you specify this option TbScanX will be disabled, but it will remain in memory. on e enable scanning. If you use this option TbScanX will be activated again after you disabled it with the 'off' option. remove r remove TbScanX from memory. This option can be used to remove the resident part of TbScanX from your memory. All memory used by TbScanX will be released. Unfortunately, removing a TSR (like TbScanX) is not always possible. TbScanX checks whether it is safe to remove the resident part from memory. If it is not safe, it just disables TbScanX. A TSR cannot be removed if another TSR is started after it. If this happens with TbScanX it will completely disable itself. noexec n never scan at execute. TbScanX normally scans files located on removable media just before they are executed. You can use this option to disable this feature completely. allexec a always scan at execute. TbScanX normally scans files to be executed only if they reside on removable media. Files on the hard disk are trusted, because these files must have been copied or downloaded before. And by that time TbScanX has already scanned them automatically. However if you want every file to be scanned before executing, no matter whether on hard disk or removable media, you should use this option. noboot b do not scan bootsectors. TbScanX monitors the disk system: every time the boot sector is being read, TbScanX automatically scans the disk for boot sector viruses. If you change a disk, the first thing DOS has to do is read the bootsector, otherwise it does not know what kind of disk is in the drive. And as soon as DOS reads the boot sector, TbScanX checks it for viruses. If you don't like this feature, or if it causes problems, you can switch it off using the 'noboot' option. This option will also save some memory because the boot sector signatures will not be loaded. ems me use expanded memory (EMS). If you specify this option, TbScanX will use expanded memory (like that provided by LIM/EMS expansion boards or 80386 memory managers) to store the signatures and part of its program code. Since conventional memory is more valuable to your programs than expanded memory, the use of EMS memory is recommended. TbScanX can use up to 64Kb of EMS memory. xms mx use extended memory (XMS). If you specify this option, TbScanX will use extended memory to store the signatures and part of its program code. An XMS driver (like HIMEM.SYS) needs to be installed to be able to use this option. XMS memory is not directly accessable from within DOS, so every time TbScanX has to scan data it has to copy the signatures to conventional memory. To be able to save the original memory contents TbScanX needs a double amount of XMS memory. Swapping to XMS is slower than swapping to EMS memory, so if you have EMS memory available swapping to EMS is recommended. Swapping to XMS may conflict with some other software, so if you experience problems try using TbScanX without the XMS option. Here is an example: Device=C:\utils\TbScanX.Exe xms noboot secure s deny access without asking. TbScanX normally asks the user to continue or to cancel when it detects a virus. In some business environments however this choice should not be made by employees. By using option 'secure' it is no longer possible to allow suspicious operations. Option 'secure' also disables option 'off' and 'remove'. lock l lock PC when virus detected. System operators can use this option to instruct TbScanX to lock the system once a virus is detected. api i load Application Program Interface. This option is intended for advanced users only. It enables the Application Program Interface of TbScanX which is needed if you want to call TbScanX from within your application. compat c increased compatibility. In most systems TbScanX performs troublefree. Another TSR program may however conflict with TbScanX. If the other TSR is loaded first, TbScanX will normally detect the conflict and use an alternate interrupt. If the other TSR is loaded after TbScanX, and it does abort with a message telling you that it has already been loaded, you can use the 'compat' switch of TbScanX (when installing it in memory). It is also possible that TbScanX conflicts with other EMS or XMS using resident software. In this case the system will hang. Option 'compat' will solve this problem, but due to extensive memory swapping the performance of TbScanX will slow down. 3.4. While scanning Whenever a program tries to write to an executable file (files with the extensions .COM and .EXE), you will briefly see the text "*Scanning*" in the upper left corner of your screen. As long as TbScanX is scanning, this text will appear. Since TbScanX takes very little time to scan the file, the message will only appear very briefly. The text "*Scanning*" will also appear if you execute a program directly from a diskette, and if DOS accesses the boot sector of a diskette drive. Detecting Viruses If TbScanX detects a suspicious signature that is about to be written into a file, a window will appear with the message: WARNING, <FILENAME> CONTAINS <VIRUS NAME>! ABORT? (Y/N) Press "N" to continue, press any other key to abort. If TbScanX detects a suspicious signature in a boot sector, it will display the message: WARNING, DISK IN <DRIVE> CONTAINS <VIRUS NAME>! PRESS A KEY... Although a virus seems to be on the bootsector of the specified drive, the virus cannot do anything since it has not been executed yet. However, if you reboot the machine with the contaminated diskette in the drive, the virus will copy itself to your hard disk. To display the name of the virus, TbScanX needs the signature file again. It will automatically use the signature file that was used when you invoked the program. If the signature file is missing (because you deleted it, or because you removed the floppy containing it), or no file handles are left, TbScanX will still detect viruses, but it is no longer able to display the name of the virus. It will display [Name unknown] instead. 4.0 Appendix: Error Messages 4.1 TbDriver Error Messages Message Meaning Another version of Tb- Driver is already resident! You started a TbDriver.EXE with another version number or processor type than the TbDriver already in memory. Cannot remove TbDriver, Unload other TSRs first! You tried to remove TBDriver from memory, but resident software has loaded after TbDriver..Resident software can only be removed from memory by unloading it in the reverse of the order it was loaded. LAN support was already installed. You tried to use the option "net" for a second time, or TbDriver already enabled network support automatically. TbDriver not active. Load TbDriver first! TbScanX needs TbDriver, so you have to load TbDriver first. TbDriver is not <version> The version of TbDriver found in memory does not match the version number of TBScanX. Make sure you do not mix version numbers! This version of TbDriver requires a <typeID> processor. This version cannot be executed by the current processor. You are using a processor optimized version of TbDriver. 4.2 TbScanX Error Messages Message Meaning Data file not found. TbScanX has not been able to locate the data file Not enough memory There is not enough free memory to process the data file. Try to enable swapping, or, if you are already doing so, try another swapping mode. *** End ***